-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python/iot3: make OTLP optional in simple API #259
python/iot3: make OTLP optional in simple API #259
Conversation
505e063
to
52aa2d9
Compare
The rust workflow fails for reasons unrelated to this PR, as no rust code was touched here. |
A very little typo in commit description "python/iot3/core: allow creating an MQTT client with explicitly no OTLP" : 'rahter' instead of 'rather' |
In the "How to test" section of PR description, the OpenTelemetry collector has to be launched in a shell that don't have to have necessarly access to python 3.11, which is not what is said in the "Note" above. In fact if we have used the commands above to have acces to a python 3.11 environment, the command of Opentelemetry launch will fail as there is no docker on the python:3.11.9-slim-bookworm used. I think that the command about OpenTelemetry launch should be put before the one of python 3.11 environment to avoid misunderstanding and be coherent with the 'Note'. |
In the "Expected results" section, I don't have the logs "test/[...]/iot3/passed: b'passed'" in the shell where I launch the test, neither "test/[...]/iot3/no-otlp/passed: b'passed' |
52aa2d9
to
2ff5212
Compare
If you are behind the VPN on the internal network, you will not be able to connect to the MQTT broker on test.mosquitto.org. Do your tests either directly on an unfiltered internet, or add proper routes. |
Ah ok, thank you. it works now even if during my first test, I had 2 failure traces in OTLP and no log for the "with otlp" test, certainly the time.sleep of 1 second can be to short... an attempt with setting timer after dropped test to 3s works and further tests with the timer at 1s worked too. |
... and fix my own identity while at it. Fixes: Orange-OpenSource#258 Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Currently, we can create an MQTT client either by passing an explicit OTLP span manager, whether real or fake, or by not passing anything, in which case no OTLP traces would be sent. However, for some callers, it might be simpler to explicitly pass 'None' to not send OTLP traces, rather than pass a fake span manager. Change the MQTT signature to accept this new use-case, in a backward compatible way. Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Currently, using OTLP is mandatory in the simple API. However, it is perfectly legit for a user to only be interested in sending MQTT messages. Similarly, it is possible that a bootstrap reply does not contain any OTLP setup when the IoT3 instance does not offer an OTLP collector Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
We currently use a loop to iterate over all the possible compression and authentication schemes, and compare their string representation against the valude from the configuration, which is a string. However, python's enum.strEnum() constructor does accept a string as a parameter, where that string is the str() representation of one of the enum values, which incidentally also plays the role of validating the value from the configuration. Use that, rather than our canned, ugly for-loop. Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
2ff5212
to
91b9356
Compare
Changes:
Closes: #236
How to test:
$
prompt means running in a shell that has access to python3.11, while the🐍 $
prompt means running in the activated venv.$ python3.11 -m venv /tmp/iot3 $ . /tmp/iot3/bin/activate 🐍 $ pip install python/iot3
Expected results:
[...]
is a hex string):